Skip to content

fix(restore): ignore __MACOSX metadata when selecting binary artifacts - #40

Open
sanghyeok-kim wants to merge 1 commit into
tuist:mainfrom
sanghyeok-kim:fix/ignore-macosx-metadata-in-binary-artifacts
Open

fix(restore): ignore __MACOSX metadata when selecting binary artifacts#40
sanghyeok-kim wants to merge 1 commit into
tuist:mainfrom
sanghyeok-kim:fix/ignore-macosx-metadata-in-binary-artifacts

Conversation

@sanghyeok-kim

Copy link
Copy Markdown
Contributor

Summary

  • Align swifterpm's __MACOSX metadata filtering for restored binary artifacts with Tuist's handling.
  • Keep workspace-state.json pointed at the actual .xcframework by ignoring __MACOSX metadata entries during artifact selection.
  • Add a regression test for binary artifact archives that contain both a real .xcframework and a __MACOSX metadata copy.

Context

Some vendor binary artifact archives include macOS zip metadata alongside the real framework:

ChannelIOFront.xcframework/
__MACOSX/ChannelIOFront.xcframework/

__MACOSX is zip metadata generated by macOS tooling. The metadata copy can still have a .xcframework directory suffix, but it does not represent the framework that should be advertised to downstream tooling.

Tuist already treats these directories as metadata when mapping remote XCFrameworks. The fallback glob filters out XCFrameworks whose parent directory is __MACOSX:

This change applies the same intent when swifterpm discovers restored binary artifacts for workspace-state.json. For affected packages, the state file could otherwise point at a metadata path:

Tuist/.build/swifterpm/artifacts/channel-talk-ios-framework/ChannelIOFront/__MACOSX/ChannelIOFront.xcframework

The restored archive contents are left intact, including __MACOSX. Only artifact selection skips metadata entries, so Tuist receives the real XCFramework path. This matches the scope of Tuist's own __MACOSX filter.

The regression test follows the same boundary. It verifies that selection excludes __MACOSX entries even when a metadata entry has a plausible .xcframework shape, rather than validating each candidate by Info.plist.

Validating each .xcframework by its root Info.plist (as SwiftPM's XCFrameworkMetadata does) could harden discovery further, but is left out to keep the change scoped to this __MACOSX artifact selection case.

Testing

  • swift build -c release --product swifterpm
  • swift test

Reproduction

// Add the package to `Tuist/Package.swift`
dependencies: [
    .package(url: "https://github.com/channel-io/channel-talk-ios-framework.git", exact: .init(13, 0, 3)),
]

// And link it to a target in `Project.swift`
dependencies: [
    .external(name: "ChannelIOSDK"),
]

Then, with swifterpm enabled (TUIST_USE_SWIFTERPM=1), run tuist install and tuist generate. Generation fails:

✖ Error
  The .xcframework at path .../__MACOSX/ChannelIOFront.xcframework/Info.plist doesn't contain an Info.plist. It's possible that the .xcframework was not generated properly or that got corrupted. Please, double check with the author of the framework.

Binary artifact discovery recognized an .xcframework by directory
extension and returned the last match. For archives zipped on macOS, a
sibling __MACOSX/<name>.xcframework metadata copy could be selected and
written into workspace-state.json, making Tuist fail with a missing
Info.plist.

Skip __MACOSX entries during discovery so selection points at the real
.xcframework. The restored archive contents, including __MACOSX, are
left untouched on disk.

Add a regression test for an archive that contains both a real
.xcframework and a __MACOSX metadata copy.
@sanghyeok-kim
sanghyeok-kim requested a review from a team as a code owner June 16, 2026 06:22
@sanghyeok-kim
sanghyeok-kim requested review from esnunes and fortmarek and removed request for a team June 16, 2026 06:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant